home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19990422-19990725 / 000121_news@watsun.cc.columbia.edu _Mon May 31 18:53:38 1999.msg < prev    next >
Internet Message Format  |  2020-01-01  |  5KB
  1. Return-Path: <news@watsun.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id SAA02607
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Mon, 31 May 1999 18:53:38 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id SAA17445
  7.     for kermit.misc@watsun.cc.columbia.edu; Mon, 31 May 1999 18:39:26 -0400 (EDT)
  8. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Subject: Re: timing problems
  11. Date: 31 May 1999 22:39:26 GMT
  12. Organization: Columbia University
  13. Message-ID: <7iv32u$h12$1@newsmaster.cc.columbia.edu>
  14. To: kermit.misc@watsun.cc.columbia.edu
  15.  
  16. In article <37530A82.194A@ix.netcom.com>,
  17. Joe H. Gallagher <dtrwiz@ix.netcom.com> wrote:
  18. : Following is two examples of K95 script code which work on a 
  19. : slower processor, but fail to work on a faster processor.
  20. : 
  21. : Example #1
  22. : 
  23. : Sending three <CR> to wake up a VAX thru a DECserver 700 to
  24. : start the login process.
  25. : 
  26. : The following code worked on a 175 Megahertz processor, but would
  27. : NOT work on a faster processor.
  28. :  . . .
  29. : :LOOP1
  30. : clear
  31. : message {Requesting username prompt...}
  32. : output \13\13\13
  33. : input 2 Username:
  34. : if success goto HAVEUSERNAME
  35. : goto LOOP1
  36. : :HAVEUSERNAME
  37. : message {Logging in . . . }
  38. : output \%a\13        ; send username
  39. : output \%p\13        ; send password
  40. : 
  41. : The faster processor required code like:
  42. :  . . .
  43. : :LOOP1
  44. : clear
  45. : message {Requesting username prompt...}
  46. : output \13
  47. : message {Synchronizing .}
  48. : output \13
  49. : message {Synchronizing . .}
  50. : output \13
  51. : message {Synchrohizing . . .}
  52. : input 2 Username:
  53. : if success goto HAVEUSERNAME
  54. : goto LOOP1
  55. : :HAVEUSERNAME
  56. : message {Logging in . . . }
  57. : output \%a\13        ; send username
  58. : output \%p\13        ; send password
  59. : 
  60. I think you answered your own question.  The faster PC sends the three
  61. carriage returns faster than the DECserver can handle them.  It's always
  62. better to build lots of robustness into a script.  You might even want to
  63. put "msleep 200" or somesuch between the OUTPUTs to ensure a minimum
  64. interval between the carriage returns.
  65.  
  66. : Example 2.
  67. : 
  68. : A DATATRIEVE procedure VALIDATION is started on the VAX.  The
  69. : KERMIT script is to wait until the procedure responds with a "Done".
  70. : The following code worked on a 175 Megahertz processor, but would 
  71. : not work on a faster processor.
  72. : 
  73. :  . . .
  74. : message {Analyzing claims . . .}
  75. : clear
  76. : output dtr execute validation\13
  77. : set count 180        ; 180 * 5 second / 60 second/min = 15 minutes
  78. : :Y1
  79. : message {Synchronizing with host during validation . . .}
  80. : input 5 Done
  81. : if success goto CONT3
  82. : reinput 0 CARRIER
  83. : if success goto ENDVAL
  84. : if count goto Y1
  85. : :ENDVAL
  86. : fatalerror {Verification never completed.}
  87. : :CONT3
  88. :  . . .
  89. : 
  90. : On a faster processor, the script file would "hang" on the line
  91. : "input 5 Done".
  92. :
  93. Most likely because "output dtr execute validation\13" sent characters too
  94. fast for the VAX, so it didn't understand the command, and therefore never
  95. said "Done".
  96.  
  97. Both cases suggest a lack of adequate flow control on the VAX and/or DECserver
  98. end of the connection.  Of course you can add pauses and (m)sleeps, or for
  99. that matter "set output pacing" commands to your script to compensate, but
  100. it's better to just fix the flow control.
  101.  
  102. : Questions:
  103. : 
  104. :  1. How does one write K95 scripts which are independent of
  105. :     the speed of PC?
  106. :
  107. By having an effective form of flow control at every juncture along the
  108. connection, or, when that is not possible, by inserting pauses and/or using
  109. "set output pacing" to control the rate at which characters are sent -- that
  110. is, to make it indpendent of the processor speed.
  111.  
  112. :  2. Which script commands are most likely to encounter timing or
  113. :     processor speed problems?
  114. :
  115. Any command that sends a block of characters.  But again, the processor speed
  116. is not the real issue.
  117.  
  118. :  3. Are these kinds of problems unique to the hardware I am using?
  119. :     to K95? or to KERMIT scripts in general?
  120. :
  121. No, they are symptomatic of a connection that lacks adequate flow control.
  122.  
  123. Look first at the connection between the DECserver and the modem.  Does your
  124. DECserver use MMJ connectors?  In that case, it does not have a full
  125. complement of modem-signal wires, and the port must be configured to sacrifice
  126. certain functions -- e.g. you can have hardware flow control, or you can have
  127. automatic hangup detection, but you can't have both.  If the ports are
  128. configured for the latter, then you must enable *local* Xon/Xoff flow control
  129. between the modem and the DECserver.
  130.  
  131. You probably would not be seeing these problems with a terminal server that
  132. uses 9-pin or 25-pin D connectors.
  133.  
  134. See Appendix II of "Using C-Kermit" for an overview of these issues.  See the
  135. VMS C-Kermit installation notes (ckvins.doc) for a discussion of DECserver
  136. configuration.
  137.  
  138. - Frank